This CO makes sense to me. Especially with the Search Related Track function.

Yeah, and it works well. It's also useful for deleting a track from disk.
I've mapped it to Shift + Trax knob press and the navigation works well: turn scroll, press confirm.

There's still an issue with submenus: in ~10% of the attmpts I can open for example the "Search related" menu but for some reason subsequent move/scroll commands are still sent to the main tracks menu. Seems to be a focus issue related to the cursor position because that determines in which direction the menu unfolds.
The current implementation may work better, though I didn't test it yet with a controller. Diff: before I used only the cursor pos, now I use the existing contextMenuEvent slot with an emulated QContextMenuEvent incl. QContextMenuEvent::Mouse reason.

Some more findings from real life testing:

• if a dialog has focus [Library], Move... controls should sent Tab / Shift+Tab keystrokes (not up/down/left/right)
• if a dialog has focus [Library], GoToItem control should sent Space instead of Enter

I can confirm that this is useful. Especially when we think of creating a touch skin.

Okay, there's interest so this could be merged?
I'll test the updated commit with my controller to see if it works 100% for submenus.

Works nicely! Tested with #4618

Can we close this PR now since it is part of #4618

No, I prefer to have those feature in separate PRs.
It's in #4618 only to simplify testing the new menu navigation. I'll rebase that once this PR is merged.

I changed the control to [Library],toggle_track_menu

Is toggle really what suits best? If we want to toggle from a script, we've allready script.toggleControl
But can I map an ESC button, which should only close, but never open a menu?

The difference is that this does not toggle the control but the context menu, only 1 is processed: you'd always use engine.setvalue("[Library],toggle_track_menu", 1); and the c++ code invokes the appropriate action.
This works fine with controllers, as well as with a future GUI / touch screen implementation where we only need a 1-state trigger button (IMO there's no point in having that button indicate the menu visibility, as well as no point in using it to close the menu as you would simply click anywhere outside the menu, as usually).

For me the new name is clear, but I don't mind to change back to the old name, if it is considered to be confusing. Just give me a hint when this is ready to be merged.

IMO I prefer the richer CO where you can actually read the state from the CO. I do not see the benefit of hiding that information via a "smarter" toggle CO.

This toggle is only for opening/closing WTrackMenu parented to WTrackTableView. The connection is made in LibraryControl > WTrackTableView (> m_pTrackMenu). It's not "smart", it's simple and efficient.
For a read/write CO an aditional connections are required, for example overriding QMenu::closeEvent and sending that all the way to LibraryControl...
Is it really worth the effort for a rather obvious widget?
What is the benefit of reading the visible state?

FWIW if the visible state is intended for elaborate scripting, this is already possible with #4618 which extends the [Library],focusedWidget enum by 4 ContextMenu(all context menus and those of the main menu bar) and 5 Dialogs.

FWIW if the visible state is intended for elaborate scripting, this is already possible with #4618 which extends the [Library],focusedWidget enum by 4 ContextMenu(all context menus and those of the main menu bar) and 5 Dialogs.

So is it possible to open these menus by setting focusedWidget to the appropriate value?
I'm worried that its a bad design for a CO that has overloaded capability (close menu when visible, open context menu when not). This seems to me like a similar mistake in design where beatjump CO would also move the loop with it when the loop was active. Lots of people didn't want that so they worked around that in their mappings. Thats why I'm saying that this new CO is "smart". Also, being a "write-only" CO makes it harder to use because its essentially opaque. Having to query another CO (focusedWidget) to be able to reason about the behavior of toggle_track_menu is an awkward API.

So is it possible to open these menus by setting focusedWidget to the appropriate value?

no, only existing library widget can be focused with [Library],focused_widget (enum 1-3).
The other values (4, 5, 6, 0) are read-only: any QMenu, any QDialog, unvategorited widgets, none

Reverted the name to [Library],show_track_menu
And I made the track menu toggle read/writeable, went quicker than I thought. Still: this works only for the WTrakMenu of the WTrackTableViews! It will not be aware of other WTrackMenu instances, so multiple menus can be open (though only the most recent one can receive keypresses, GoToItem and MoveUp/Down/Vertical, with #4618)

this works only for the WTrakMenu of the WTrackTableViews

Thank you. I think this is fine as long as we document it as part of the MixxxControls.

Sure, I'll update the manual after merge.

Documentation comments updated, rebased, squashed, ready for review!

(forgot to git add some comments)

This is mergeable now. However some conflicts have been developed.

I'll take care of it in two weeks.

This is mergeable now. However some conflicts have been developed.

Fixed, ready for merge

Thank you!